SystemView
The real-time software analysis tool from SEGGER
SystemView records the runtime behavior of an embedded system for in-depth analysis and visualization.
Overview
SystemView is a real-time recording and visualization tool for embedded systems. It reveals the true runtime behavior of an application, going far deeper than the system insights provided by debuggers. This is particularly effective when developing and working with complex embedded systems comprising multiple threads and interrupts. SystemView can ensure a system performs as designed, track down inefficiencies, and find unintended interactions and resource conflicts.
Key features
- Continuous real-time recording of an embedded system
- Capture tasks, interrupts, timers, resources, API calls, and user events
- Recording via J-Link and SEGGER RTT Technology, IP, or UART
- Live analysis and visualization of captured data
- Minimally system intrusive
- Works on any CPU
- Works with any RTOS and with bare-metal systems
- SEGGER embOS, emNet, and emFile API call tracing as standard
- uC/OS-III, Micrium OS Kernel, FreeRTOS, NuttX and Zephyr instrumentation included
- Free for non-commercial use without limitation
Supported RTOS
Currently embOS, uC/OS-III, Micrium OS Kernel, FreeRTOS, NuttX and Zephyr can be used with SystemView out-of-the-box.
Recording events
On the target system, SystemView records events that happen during runtime. These can be interrupts, timers, task switches and scheduling with an RTOS, API function calls and returns, or user events and messages. The events are retrieved, analyzed and visualized in the SystemView application, while the target keeps running. The Events Window in SystemView displays the recorded events along with more information.
To maintain low communication overhead on the target system, SystemView only records basic information.
SystemView analyzes all information from the events and shows:
- The API function name and its parameters and values
- The recording time or system time when the call happened
- The task in which the call happened
- The duration of the API call
Sample output: "API function with Id x has been called with parameter values y and z and n ticks after the last event”.
A regular event is 4 to 8 bytes long and takes about 1 µs to be recorded at 200 MHz. With 10,000 events per second the overhead added by SystemView is less than 1% of the CPU time and the amount of data is easily within the bandwidth limits of the recorder.
The timestamps for events can be as accurate as 1 CPU cycle, which equates to 5 ns on a 200 MHz CPU.
Event Timeline window
Most embedded systems do not have linear code execution. They implement interrupts for timers and use of peripherals, or might use an RTOS with multiple tasks.
The target generates events on enter and leave of interrupts, when tasks become ready for execution, and when a task starts or stops execution. The SystemView Application plots these events in the Timeline window and shows the context in which they happen.
This enables easy analysis of when, how long, and why tasks run or what happens on an interrupt.
This helps identify issues and inefficiencies, such as:
- Incorrect task priorities or priority inversion leading to starvation
- Incorrect inter-task communication
- Inefficient delays and timeouts
- Questionable or unnecessary interrupts
DataPlot window
SystemView's data recording features provide deeper insight into system behavior. Recorded data includes variables, sensor data, states or any other custom data. All recorded data is directly synchronized with events and anything else recorded with SystemView. To view the data, the DataPlot window provides a scope-like visualization that is consistent with SystemView's Timeline and CPU load windows.
With the ability to monitor variable data alongside runtime events, developers can easily identify and analyze system behavior, pinpoint anomalies, and optimize performance. The DataPlot window supports high sampling rates, offers customizable visualization options, and allows decoding of multiple variables in different formats for precise and detailed analysis.
Context Statistics window
SystemView allows users to identify blocking reasons. The Context Statistics window presents detailed information on a task’s total active time, blocked time, and suspended time. Additionally, the blocked time is categorized into segments such as blocks caused by interrupts, other tasks, or the scheduler, and it shows the specific task or interrupt responsible for the block.
Users can select the task they wish to analyze via a drop-down menu. In addition, the ‘Hide when empty’ checkbox allows for a clear overview, showing only events that have actually occurred.
Optimizing the performance of tasks
CPU cycles are limited on embedded systems, making it important to optimize the performance of tasks as well as to get the order of execution and the time distribution right.
With the CPU Load Window, SystemView helps analyze where CPU load is high. By knowing what happens at or before high-load times, the system can be tuned to avoid bottlenecks which may lead to delayed execution of important tasks.
The Runtime Window provides additional information about the runtime distribution of contexts. It can be used to verify that each context runs within its timing limits or to find cases where a context unexpectedly runs too long.
Tracking and measuring performance
SystemView sets up events especially suited to mark certain points in a target system. To easily measure the duration from point A to point B, or from point A through B to point C, marker start, mark, and marker stop events can be generated. The SystemView application automatically links corresponding markers and adds more information, such as run time and run count of the measurement.
Logging output
SystemView includes logging of messages with a recording. Simple strings can be recorded as a log, warning, or error message. The logging functions support formatting of strings, similar to printf(). Since formatting strings can be time-consuming and requires additional memory, this can be deferred to the SystemView Application. The target system simply records the format string and the parameters in an event. Then the SystemView Application takes care of formatting the string and prints it in the Terminal Window.
Heap monitoring
SystemView monitors heap memory allocation. In many cases, memory can be allocated for the lifetime of the application without a problem. A problem occurs when the peak load of the heap increases over time, i.e. the application is consistently increasing the amount of memory it uses. This means the application is leaking memory and will eventually run into trouble. With SystemView’s heap memory monitoring it is easy to see where memory allocations are made, providing clues to where the leak may be.
Media gallery
SystemView— Context Statistics Window
SystemView — Event tracing
SystemView — Intro
SystemView — Webinar
SystemView — Roundtable EW21
Licensing
SystemView is available as a SEGGER Software Tool under SEGGER's Friendly License for non-commercial use and SEGGER's Commercial-use License. Licenses for SystemView are perpetual for as long as you want to use it. No annual subscription is required.
*Discount applies to second license and all additional licenses of the Commercial-use License.
FAQ
Q: Can I use SystemView while I am debugging my application?
A: Yes. SystemView can run in parallel to a debugger and do continuous recording. To make sure that data can be read fast enough, configure the debugger connection to a high interface speed (>= 4 MHz). Parallel connections to a target are currently only supported on Windows and Linux.
Q: Can I use SystemView with my J-Link LITE or J-Link OB?
A: Yes. In general, SystemView can in general be used with any J-Link. J-Link LITE and J-Link OB are limited in the debug interface speed. This leads to overflow events when the RTT buffer cannot be read fast enough and the system creates too many events. To get a full-featured J-Link, take a look at the purchase options.
Q: Can I use SystemView with my old J-Link?
A: Yes. SystemView can, in general, be used with any J-Link if the J-Link supports the target core. Older J-Links (V8 and older) might have limited RTT capability. This can also lead to overflow events when the RTT buffer cannot be read fast enough and the system creates too many events. To trade-in or upgrade your J-Link, have a look at our purchase options.
Q: Can I do continuous recording on Cortex-A or Cortex-R devices?
A: This depends on the target. RTT requires memory access on the target while the target is running. On Cortex-A and Cortex-R, this is done via the AHB-AP. If a target device has an AHB-AP, SystemView can continuously record.
Q: Can I do continuous recording on ARM7, ARM9?
A: No. RTT requires memory access on the target while the target is running. On these devices, only single-shot and post-mortem modes are supported.
Q: I don't use embOS or FreeRTOS, can I still use SystemView for my application?
A: Yes. SystemView can be used with any (RT)OS. For Task and OS execution recording, the OS might have options to hook up trace/profiling instrumentation modules where SystemView can be added. Otherwise, the OS must be instrumented to be able to do so. When in doubt, get in contact with an OS vendor. If instrumenting the OS isn't possible, you can still use SystemView to record interrupt activity and user events.
Q: I don't use any OS at all. Should I still use SystemView?
A: Yes. Even without any OS, SystemView can be used to record interrupt activity, to verify that interrupts occur as expected, and to record user events which can be used to measure module execution times.
Q: I get overflow events when continuously recording. How can I prevent this?
A: Overflow events occur when the SystemView RTT buffer is full. This can happen for the following reasons:
- J-Link is kept busy by a debugger and cannot read the data fast enough.
- The target interface speed is too low to read the data fast enough.
- The application generates too many events to fit into the buffer. To prevent this:
- Minimize the interactions of the debugger with J-Link while the target is running. (i.e. disable live watches)
- Select a higher interface speed in all instances connected to J-Link. (i.e. The debugger and SystemView)
- Choose a larger buffer for SystemView. (1 - 4 kByte)
- Run SystemViewer stand-alone without a debugger.
Q: My application crashes when I connect SystemView. What might be wrong?
A: Make sure ~200 Bytes of stack are available for SystemView in every context (Task, Interrupt, Scheduler) which can create SystemView events.
Q: I cannot start recording in SystemView. What might be wrong?
A: Possible reasons are:
- J-Link or target is not connected: Make sure all connections are okay.
- The target is not running: Make sure the target is running, otherwise connection might fail or the RTT Control Block cannot be found.
- The SystemView module is not configured: Make sure the SystemView module is included in your application and SEGGER_SYSVIEW_Conf() is called at the start of the application.
- The J-Link Software is out-of-date: Make sure you have the latest J-Link Software and Documentation Package installed.
Q: SystemView cannot find the RTT control block. How can I configure it?
A: Auto-detection of the RTT Control Block can only be done in a known RAM address range after it is initialized. Make sure the application startup has run when starting to record. If the RTT Control Block is outside the known range for the selected device, either select 'Address' and enter the exact address of the RTT Control Block or select 'Address Range' and enter an address range in which the RTT Control Block will be.
Q: I receive invalid packets. How can this happen?
A: Invalid packets are mostly generated by the target system for one of two reasons:
- SystemView does not correctly lock when recording an event and is interrupted by another event. In this case make sure SEGGER_SYSVIEW_LOCK() and SEGGER_RTT_LOCK() are configured correctly for your device.
- The system goes into sleep or low-power mode and the J-Link cannot correctly access the RAM to read the SystemView buffer. It is recommended to not use WFI or any low-power mode while a debug probe is connected to the system.
Q: Do I have to select a target device to start recording?
A: Yes. J-Link needs to know which target device is connected. The drop-down lists the most recently used devices. To select another device simply enter its name. A list of supported devices can be found here.
Q: My question is not listed above. Where can I get more information?
A: For more information and help please post your question in the SEGGER Forum.